This does all the work that will be required to pause ChannelMonitorUpdate flight until an Event completes, but doesn't actually use the new behavior. Sadly, I think we should consider splitting this work across release, as the commit Track an EventCompletionAction for after an Event is processed indicates -

Note that this gets dangerously close to breaking forwards
compatibility - if we have an `Event` with an
`EventCompletionAction` tied to it, we persist a new, even, TLV in
the `ChannelManager`. Hopefully this should be uncommon, as it
implies an `Event` was delayed until after a full round-trip to a
peer.

Still, I'm open to discussion on it - Events generally should be reliably processed before a full round-trip happens, and it sucks to fix major bugs across releases just over worry of a hopefully-very-rare race breaking forwards, but not backwards, compat.